🦋 Changeset detected

Latest commit: 82a5240

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

Thanks for the contribution. For me non-yolo mode still auto approves the commands (even though the buttons show).
I think the main problem is that there is a missing case handler in the AgentManagerProvider.ts to handle agentManager.respondToApproval

I think the main problem is that there is a missing case handler in the AgentManagerProvider.ts to handle agentManager.respondToApproval

@marius-kilocode Thanks for testing! The agentManager.respondToApproval handler is already implemented (line 278 of AgentManagerProvider.ts).

Could you check if you have a local CLI configuration that auto-approves echo? Try with a command that isn't auto-approved by default to confirm the approval flow works as expected.

I dug a bit further. If i switch in an independent CLI to yolo mode the approval buttons don't work anymore. Once I switch back in a separate CLI to non-yolo the buttons work. I suspect this might either be a bug attached to:

//The code in question (cli.ts:287-295):
  // In JSON-IO mode, don't set yoloMode on the extension host.
  // This prevents Task.ts from auto-answering followup questions.
  // The CLI's approval layer handles YOLO behavior and correctly excludes followups.
  if (!this.options.jsonInteractive) {
      extensionHost.sendWebviewMessage({
          type: "yoloMode",
          bool: Boolean(this.options.ci || this.options.yolo),
      })
  }

which we might just remove now as we disabled the question tool in yolo mode on main. Or it is some global state architecture issue that somehow shares global yolo config state in between agent manager/cli sessions.

I investigated the echo auto-approve behavior. It's actually due to the default CLI config, not yoloMode:

// cli/src/config/defaults.ts
execute: {
    enabled: true,
    allowed: ["ls", "cat", "echo", "pwd"],
    denied: ["rm -rf", "sudo rm", "mkfs", "dd if="],
}

echo is in the default allowed list, so it auto-approves regardless of yoloMode. Try with a command not in this list (e.g., touch test.txt) to test the approval flow.

Still investigating the global state issue you mentioned separately.

@marius-kilocode Regarding your observation:

If i switch in an independent CLI to yolo mode the approval buttons don't work anymore. Once I switch back in a separate CLI to non-yolo the buttons work.

I'd like to understand better what's happening. Here's what I think the issue might be:

My understanding:
When you toggle YOLO mode in an independent CLI (via terminal), the Agent Manager session doesn't know about this change. There's no synchronization between the CLI's yoloMode and the Agent Manager's session state.

Proposed solution:
I've implemented bidirectional YOLO mode sync:

• A toggle button (⚡) in Agent Manager session header to change yoloMode for running sessions
• When toggled in Agent Manager → sends setYoloMode to CLI via stdin
• When toggled in CLI → emits yoloModeChanged event back to Agent Manager

Questions:

1. Is this the issue you're experiencing? Or is it something else?
2. When you say "independent CLI", do you mean a CLI launched from VS Code terminal, or from the Kilo Code main panel, or something else?
3. Can you describe step-by-step how to reproduce the issue?

I want to make sure I'm solving the right problem before pushing the fix.

@marius-kilocode You were right! I misunderstood the issue - it wasn't about synchronization, but about global state pollution.

The code in cli.ts was sending a yoloMode message to the extension host, which modified the global state shared by all sessions. When you launched a CLI with --yolo outside of Agent Manager, it "polluted" the global state and affected Agent Manager sessions.

Fix applied (commit 5b6c869d8d):

• Removed the code that sends yoloMode to the extension host
• Updated toggleYoloModeAtom to only modify local state
• Each CLI instance now manages its own yoloMode state locally via yoloModeAtom
• Agent Manager sessions have their isolated yoloMode through the --yolo flag passed to each CLI process

Ready for review! Thanks for taking the time to dig into this and identify the root cause 🙏

Also worth mentioning: this PR is highly anticipated on my end. The automatic YOLO mode behavior is seen as a significant concern in my company, and it's currently a blocker for wider adoption. Having proper control over auto-approval per session would really help address those security/governance concerns.

@Drilmo I will prio it, thanks for the feedback!